Distributed client/server systems have become a standard architecture for the implementation of databases, web servers, application servers, etc. Accesses that are made to the data stored in such systems are known as transactions. Transactions that modify data stored in server systems present certain challenges in the operations of a distributed server system. Many commercial transaction-processing systems use the two-phase commit protocol, which requires a series of messages to be exchanged between a transaction manager and the resource managers. A transaction can end in two ways: a commit, which is the successful execution of each step in the transaction, or a rollback, which guarantees that none of the steps are executed due to an error in one of those steps.
All transactions share the following properties: atomicity, consistency, isolation, and durability (represented by the acronym “ACID”). Atomicity refers to indivisible operations, i.e., operations which will either complete fully, or not at all. Consistency refers to a transaction transitioning persistent data from one consistent state to another. If a failure occurs during processing, the data must be restored to the state it was in prior to the transaction. Isolation refers to transactions not affecting each other. A transaction in progress must be isolated from other transactions. Although several transactions may run concurrently, it should appear to each transaction that all the other concurrent transactions completed before or after it. All concurrent transactions must effectively end in sequential order. If other transactions were allowed to read data that is uncommitted, those transactions could end up with inconsistent data if the transaction is rolled back, or end up waiting unnecessarily if the transaction commits successfully. Durability refers to the persistence of the transaction. Once a transaction has successfully committed, state changes committed by that transaction must be durable and persistent, despite any failures that occur afterwards.
Regardless of the claimed reliability of a system, failure of the system is always a possibility. For the transaction processing system to function properly in the face of a failure, the transaction manager must log information to a non-volatile store that can be used to recover a transaction processing failure. A recovering transaction is one that is reconstructed as a result of a previous failure in the processing of a transaction.